Building 3D Applications with 3D Components and 3D Frameworks

Since 3D graphics applications (like entertainment, information visualization or training applications) are getting more and more complex it is necessary to improve the production process. Software engineering concepts, which were developed to build large software systems in a fast and reliable manner, offer promising solutions. In this contribution we will present an adaptation of framework and component concepts to 3D graphic to improve development speed and stability of 3D applications. We will point out the problems of this adaptation and we will suggest solution for them. A Java and Java3D based implementation as well as its usage in a large 3D application is presented and discussed. Introduction One main obstacle for a widespread use of 3D computer graphics is the fact that their production is more difficult as well as more time and cost consuming. Complexity is a concern as graphics hardware made a tremendous progress and allows the display of complex 3D scenes. The production process usually starts from scratch. Reuse is neither common nor organized, often at most some geometric models or textures are reused. Another major problem is that 3D computer graphics are produced in a format (e.g. as a video) that makes it difficult to integrate in an application with interaction possibilities more than just start, stop and pause. Authoring tools (if they exist) provide complex functionalities (like 3D Studio Max [Kine00] or Maya [Alia00]) and are aimed for an expert in computer graphics authoring [Rou00]. Thus, the group of potential authors is limited to people possessing in depth animation and modeling knowledge, programming skills and at least some talent in art for modeling nice geometry models. One solution for allowing new types of authors, allowing reuse, managing complexity and having a cost-efficient production process promises to be the application of components and framework concepts and methodologies [Faya99] to 3D computer graphics. Our contribution is organized as follows. We will introduce a concept of 3D components and 3D frameworks and we will point out the differences to the original software engineering concept. Afterwards we will present an example implementation of our concept. But let us start with a short overview about existing technologies. Background The idea of an encapsulation of geometry and behavior can be found in several areas of computer graphics applications. Conner et al used component concepts in the context of building a three-dimensional user interface using 3D graphic primitives, which include their behavior [Conn92, Zele93]. The work was motivated through the use of widgets in 2D applications like OSF/Motif or Xview [Myer89]. Since 3D space has inherently more degrees of freedom than 2D user interfaces the effort to describe the behavior increases. The bad integration of interaction handling in 3D graphic toolsets made it necessary to develop a concept for a better geometry and behavior integration. This encapsulation of geometry and behavior was called 3D widget. The developed framework handled the user interaction by sending callbacks to the 3D widgets. An example implementation includes 3D widgets for a virtual sphere, handles, snapping, a rack and a cone tree. A second idea is to build 3D visualization components for business visualizations [Scho00]. The motivation was to have a library of interactive 3D visualization components to use the power of human intuition in informationrich decision tasks. Within a component, geometry is associated with behaviors. The framework maps the source data to the embedded 3D visualization components. Example component implementation of a 3D cone tree, a 3D histogram and a 3D graph was done. A definition of 3D components and 3D frameworks was given in the context of specifying X3D [X3D00]. X3D expresses the geometry and behavior capabilities of the Virtual Reality Modeling Language (VRML) [VRML97] using the Extensible Markup Language (XML) [XML00]. VRML is used for distributing 3D graphics content over the web. One proposal for X3D defines an X3DComponent as “an element of functionality describable by an interface of types and names. [...] They are usually designed to be simple in purpose but can also be composed to form complex constructions, which represent higher order semantic abstractions. A framework is a collection of semantically related components associated by composition, event-wiring, method invocation and property query and modification”[Rudo99a]. These examples from literature show that neither the definition nor the use of 3D components and 3D frameworks are uniform. All examples use 3D components and 3D frameworks in a very special way. Thus, it is difficult to use the presented concepts for other areas of 3D computer graphics. Concept The goal of this contribution is to present the concept of 3D components and 3D frameworks. Therefore, let us focus on points that make a distinction between components representing a 3D graphics entity and components in general. When specifying what we consider to be a 3D component we incorporate some features that have proven to be advantageous for components in general. These features are: Event-based communication, Reflection, Persistence, Customization. Analyzing the state of the art of applying component concepts to 3D computer graphics we have already identified three additional issues: geometry, behavior and encapsulation: Geometry includes data about the shape of the 3D component (e.g. as polygon meshes with normal fields), its appearance (e.g. color, surface attributes, textures), transformation (e.g. translation, orientation) and additional information (like lighting, 3D sounds). One requirement for a 3D component is that it is able to administrate these data. A peculiarity of 3D components is that they are not necessarily static, they change their state over time. For instance, they can be animated, react on user interactions or change internal state variables. This is called behavior. Behavior has to be represented in the 3D component and has to be linked to the geometry because some behavior parts affect the 3D component’s geometry. Encapsulation means that a 3D component can only be accessed via its interface, i.e. we want to have a black box component. As there are some parts of the interface that are special for a 3D component we want to distinguish three parts of the 3D component’s interface: First, the basic interface which is needed for basic features like component reflection, event handling and persistence. Second, the geometric interface which includes access to methods enabling interaction with an underlying graphic toolset. The 3D component has to provide information for the graphic rendering process. Third, the behavior interface provides access to the behavior description and the rest of the component. Note, that the basic and the geometric interface are fix. The behavior interface is the only part of the component interface, which can be defined individually for each component. For example, a part of the behavior interface can be defined freely by the specification of events. In the basic interface there is only access to functionalities for sending and receiving events, which stay the same for all kinds of events in every 3D component. To sum up, our concept of a 3D component is as follows. A 3D component is an encapsulation of geometry and behavior. In addition, it provides basic features like event scheduling, component reflection, persistence and customization. The geometric part of a 3D component includes all geometric data as well as the administration of the geometric hierarchy in form of a scene graph. The encapsulation provides a basic interface, a geometric interface, and a behavior interface. Figure 1 depicts the according architecture of a 3D component and shows how the different parts work together. Note, that there are two levels where 3D components can be connected: at geometry level and at communication level.